某城商行基于 VPLEX+Recovery Point 的存储灾备方案
【关键词】城商银行、灾备、双活、两地三中心
1. 概述
1.1 项目背景
长期以来，由于监管导向和业务连续性要求，国内银行业信息系统普遍强调业务系统的高可用性和高稳定性。经过十多年的建设发展，我行现有系统规模逐渐扩大，在当前的发展趋势下，我行应用系统大量采用 X86 架构服务器，Power 小型机主要用于关键业务数据库，此外 Power 小型机架构平台上还运行着数十套老旧的业务生产系统。随着使用年限的增加，计算存储资源已经饱和，设备老化严重，进入故障高发期，相关问题亟待解决。
另外随着新一代核心系统项目群的上线，对计算和存储的资源的需求快速增加，并需要重新构建新系统的容灾体系，满足业务连续性的监管要求。
1.2 建设目标
通过新购服务器和存储设备，采用新的架构进行容灾的设计，有望达成本次项目目标： 一是对部分老旧设备升级换代，为业务系统提供安全稳定的生产资源；二是满足新一代核心系统项目群系统的上线计算资源、存储资源需求；三是满足两地三中心的容灾规划建设，最终实现同城双活+异地容灾体系，增强业务连续性保护，较好的满足监管要求。
2. 方案规划设计
2.1 原系统架构
原生产环境分为以 X86 虚拟化为主的资源区和以 Power 小型机为主的资源区， 两个资源区资源相对独立，如下图所示：
目前Power 小型机资源区存在的问题主要集中在以下几点：
1、需要提供足够的资源满足新一代核心系统项目群的系统上线，而 Power 小型机资源区计资源和存储资源严重不足，急需进行扩容。
2、IBM DS8000 的存储设备老化严重，故障率增高，需要更新换代。
3、新系统上线后需要重新进行容灾系统的规划设计。
为了解决以上问题，基于Dell EMC VPLEX+Recovery Point 的架构重新进行小型机资源区的容灾设计，以满足新一代核心系统项目群系统上线的资源需求，并建立新系统的灾备体系，满足业务连续性的需求。
2.2 方案总体设计
考虑到同城灾备机房和异地灾备机房建设进度，整个项目分两个阶段进行。
第一阶段，完成存储设备的更新换代，并将原有系统平滑迁移到新的存储，并支撑新一代核心系统项目群系统上线。
第二阶段，完成同城双活+异地容灾的灾备体系建设。
最终方案采用 Dell EMC VPLEX Metro+Recovery Point 方案来构建两地三中心数据存储方案。
VPLEX 的关键能力 AccessAnywhere 是通过分布式一致性缓存技术(Distributed Cache Coherenece)来实现，在集群内及跨区域的另一集群间完成缓存数据的一致性；实现跨主机、跨集群、跨数据中心的访问和在节点之间同步镜像。 VPLEX 通过把控制器的单个内存系统进行合并以形成分布式缓存。分布式设计可以跨 VPLEX Metro 和 Geo 系统进行扩展，以提供全局系统的缓存连贯性和一致性。
分布式一致性缓存技术在实现上面，并没有强求所有的 Cache 都保持统一，而是基于目录形式来跟踪细小的内存块通过锁的粒度来加强扩展能力。 每个引擎的 cache 分为本地Cache (Cache local)和全局 Cache (Cache global)。
读的时候先读 Director 的 Local Cache ，如命中直接读取；如在 Global 中命中，则从对应的引擎 Cache 中将其读取到 Local Cache，再反馈主机；如没有命中，则从本地后端的存储中读取到 Local 中，并同时修改 Local 和Global Cache 中的信息与索引信息。
写数据时， VPLEX Local 和 Metro 都采用透写方式。VPLEX Local 待数据写入后端的磁盘阵列后，才会向主机回应写完成，而 VPLEX Metro 需要待数据写入两地的磁盘阵列后， 才会向主机回应写完成。VPLEX Metro 架构下写操作处理如下：
1.主机发送写操作到VPLEX 的 Director
2.Director 收到写请求时，将写操作发送给另外一个站点的 VPLEX
3.Director 先判断是否在 Local、Global Cache 中有对应的旧数据，如没有直接写入后端存储的 cache；如有旧数据，先废除 Local、Global Cache 中旧数据再写入后端存储 cache
4.写入后端存储 cache，反馈写操作完成
5.远端站点的 VPLEX 将写操作结果返回给本地站点的VPLEX
6.只有VPLEX Metro 的两边的存储都写成功，才会返回主机写操作成功
2.2.1 第一阶段规划设计
第一阶段需要将新购的 VPLEX、VMAX100K 进行安装并接入 FC 网络，完成数据的迁移。如下图所示：
在实施前需要对原有环境进行调研，梳理 FC SAN 网络，并分析原来IBM DS8000 存储的 IOPS 和带宽使用情况，规划好 FC 交换机级联的带宽并做到充分的冗余。另外需要梳理 IBM DS8000 上各个系统 volume 的映射情况。
考虑到银行关键业务系统 7*24 小时提供服务，故如何减少停机时间并平滑的进行数据迁移是关键。采用 Dell EMC VPLEX 存储网关来进行DS8000 存储系统的磁盘封装，将应用系统和数据库接入 VPLEX 的环境，这样 VPLEX 完成磁盘封装和映射给操作系统后，经过重新识别磁盘可快速恢复业务系统缩短停机时间，经过前期的论证和测试，可在人行的 8 小时停机窗口完成该操作并恢复业务系统的正常运行。之后再利用 VPLEX 的 Mobility 功能进行存储上数据的无缝切换。
下面对整个过程分别进行说明：
2.2.1.1 存储网关接管应用 IO
在 VPLEX 环境中，对后端存储系统的磁盘设备采用整盘封装的方式下，可以将应用系统完整的迁移到 VPLEX 环境中，迁移步骤简述如下：
1.在主机上，停止应用系统的运行。并进行数据库及重要文件系统内容的备份。
2.停止数据库。
3.在主机上，停止 HACMP 运行。停止后建议在主机上重新启动 HACMP 进行验证， 如存储单机或VG 没有加入 HA 资源组，需单独将VG varyon 检查，验证 VG 是否正常，以免封装后出现异常的情况下排错较为繁琐，必要由此造成实施过程中需要进行回退。
4.在主机上，删除相应的原存储系统的磁盘设备和VG 信息。
5.在主机上，安装支持 VPLEX 的 Dell EMC ODM 软件包（Dell EMC.Invista.aix.rte、Dell EMC.Invista.fcp.rte）和 Powerpath 软件，必要时卸载原阵列的多路径软件。
6.在原 DS8000 存储系统上，取消主机对磁盘设备的访问（可选）。
7.在 SAN Switch 上，删除主机 HBA 卡与原存储系统前端之间的 ZONE。并增加主机 HBA 卡与 VPLEX 前端口之间的ZONE。
8.在 DS8000 存储系统上，赋予 VPLEX 对磁盘设备的访问。
9.VPLEX 扫描新分配的后端 DS8000 存储磁盘设备。
10.VPLEX“封装”新分配的后端存储磁盘设备。识别（Claim）新分配的后端存储磁盘设备。创建“Extent”。将每个新分配的后端存储磁盘设备，“整盘封装”成一个 Extent。
11.使用 DS8000 封装后的“Extent”在 VPLEX 上创建“1:1 Mapping of Extents to Device”的 Device。
12.在 VPLEX 上使用“1:1 Mapping of Extents to Device”的Device 创建virtual volume。
13.主机 HBA 在 VPLEX 进行 Initiator 的注册。Host Type：AIX 主机选择 aix， Windows 主机选择 default。
14.创建 Storage View。在 VPLEX Cluster 上创建 Storage View，添加 VPLEX 前端口、 Initiator 及 virtual volume。
15.在主机上，识别和配置 VPLEX 的磁盘设备。在 VIOS 主机或 HACMP 上，调整VPLEX 的磁盘设备的 reserve_lock/reserve_policy。
16.在主机上，启动应用系统和数据库。
完成以上步骤后， VPLEX Local 中 virtual volume 逻辑结构如下所示：
通过 VPLEX 封装 DS8000 的 volume，不改变原来 DS8000 上的任何数据，同时原来的两套 DS8000 之间的 Metro Mirror 保持同步状态，始终保持在两套 DS8000 上各有一份完整的数据。 VPLEX 接入存储环境后，IO 读写方式发生了变化，但该变化对于主机来说是透明的。
2.2.1.2 存储数据迁移
在上一步已经完成 VPLEX 接管主机的IO，要完成存储数据的迁移，需要使用 VPLEX 的另一项功能Mobility。
VPLEX Mobility 功能，允许无中断地将数据块或设备上的数据移动到同一集群中的其他数据块或设备，或从一个集群中的设备移动到另一个集群中的设备。利用该功能可以方便的将 DS8000 上的数据迁移到新购的 Dell EMC VMAX100K 存储中。
提前将 Dell EMC VMAX100K 存储接入到 VPLEX 中，按 DS8000 上的卷的数量和容量大小信息 1:1 的在VMAX100K 中分配好 Volume，并将VMAX100K 中分配好的Volume 映射给 VPLEX，由 VPLEX 进行封装。创建 Raid-1 的 device，然后使用 Mobility 的功能进行数据的迁移。
图.开始数据迁移
VPLEX 将数据从 DS8000 在线同步到VMAX 100K，在数据完成同步后，DS8000 的device 将会退出，直接使用 VMAX 100K 的 Device。整个过程对于主机是透明无感知的， 期间无应用或数据库的中断和数据丢失。
图.数据迁移完成后
2.2.1.3 配置本地镜像
完成数据迁移后，为保证整个架构中无单点故障设备的存在（ VPLEX 采用了双引擎 4 个 Director 的配置），在 VPLEX 中配置 Local Mirror，在两套VMAX100K 存储间配置镜像，做到存储设备的冗余。
配置 Local Mirror 后， VPLEX Local 中 virtual volume 逻辑结构如下所示：
卷镜像创建完成后，当主机对镜像 LUN 下发写请求时，镜像 LUN 会将主机写 IO 同时转发给两个镜像副本，即对两个镜像副本进行双写操作。当两个镜像副本都写数据成功后， 将写结果先返回给镜像 LUN，再由镜像 LUN 将读结果返回给主机。对两个镜像副本进行双写，保证了两个镜像副本的数据一致性。
至此，已经完成了 DS8000 存储更换为 VMAX 100K，并在本中心配置了存储间的冗余。
2.2.1.4 配置 CRR 数据保护
VPLEX 只提供了存储异构虚拟化和镜像的功能， 快照， 复制等特性需要添加RecoverPoint 实现，所以 VPLEX 的组网方式常常会考虑配合 RecoverPoint 一起使用。RecoverPoint 提供以下几种复制功能：
连续数据保护（RecoverPoint CDP）
连续数据保护持续地抓取变化数据并将其保存到本地，保证了本地数据可以恢复到任何 一个时间点而无数据丢失。CDP 能够在本地群集内的一个阵列或多个阵列中本地复制 LUN。请务必谨记，如果本地系统发生故障，则无法访问本地拷贝。
CDP 的写操作流程：
1.应用服务器向 LUN 发送一个受 RecoveryPoint 保护的写请求。拆分器会截取这个写请求
2.拆分器拆分了写请求并将它同时发送到生产卷和 RPA
3.当 RPA 收到写请求时，将确认信息发送回拆分器
4.RPA 将数据连同时间戳以及任何与该写操作相关的应用、事件或用户生成的标签一起写入本地日志卷
5.RPA 成功的将数据存储在日志卷之后，再将它分发到 CDP 拷贝，在分发过程中保留原来的写顺序
连续远程复制（RecoverPoint CRR）
RecoverPoint 远程复制能够将 LUN 复制到远程阵列或群集。RecoverPoint 远程复制在同步和异步模式中均可用 ， 并可根据用户定义的策略进行修改。RecoverPoint 远程复制还能够执行双向复制。
CRR 的写操作流程：
1.应用服务器向 LUN 发送一个受 RecoveryPoint 保护的写请求。拆分器会截取这个写请求。
2.与 CDP 类似，拆分器拆分了写请求并将它同时发送到生产卷和 RPA。
3.当 RPA 收到写请求时，将确认信息发送回拆分器（启动同步远程复制的情况除外）。在同步复制中，确认信息将被延迟直到恢复站点接收到写请求。
4.当本地 RPA 接收到一个写请求之后，将它与其他写请求绑定，去除重复数据、排序、加时间戳并打包压缩，与校验数据一起通过 IP 网络传送到远程 RPA。
5.恢复站点收到数据包之后，远程 RPA 校验数据以确保数据包在传送过程中无损坏，然后解压数据。
6.远程 RPA 将数据写入在恢复站点的日志卷。
7.数据被写入到日志卷后，分发到 CRR 拷贝，并保留原来的写顺序。
并发本地和远程数据保护（RecoverPoint CLR）
RecoverPoint CLR 并发本地和远程复制能够进行本地和远程复制。它提供了针对相同LUN 的同步数据块级别本地和远程复制。可以恢复其中一个拷贝，并且不会影响另一个拷贝。它还支持双向复制和任意时间点恢复能力。
充分考虑设备的冗余，避免 VPLEX 出现故障或者 VPLEX 后端存储全部故障后不能进行数据的恢复，在生产中心未采用 CDP 的保护方式，而采用了 CRR 的方式，将连续性保护数据放置在独立的存储（未接入 VPLEX），出于成本的考虑，采用 Dell EMC unity 的存储作为 CRR 保护的数据存储。为避免对生产环境的性能造成影响，Recovery Point 使用异步模式进行CRR 数据保护。
1.应用服务器向 LUN 发送一个受 RecoveryPoint 保护的写请求。 VPLEX 拆分器会截取这个写请求
2.VPLEX 拆分器拆分了写请求并将它同时发送到生产卷和 RPA
3.当 RPA 收到写请求时，将确认信息发送回拆分器
4.RPA 将它与其他写请求绑定，将数据写入在恢复存储的日志卷
5.数据被写入到日志卷后，分发到 CRR 拷贝，并保留原来的写顺序
2.2.2 第二阶段规划设计
建立同城双活+异地容灾的两地三中心容灾体系，并完善数据的保护机制，建立多层次的防范机制，来保障数据的可靠性和安全性。其中存储双活技术只是一个层面，只能在存储故障或者站点级的灾难时提供数据保护，对于逻辑错误和误操作却无能为力，故需要在建立同城双活的基础上辅以备份技术、数据库复制技术，连续性数据保护技术，建立了完善的数据保障体系。
2.2.2.1 同城双活
同城中心按照信息系统灾难恢复等级 6 级的标准进行建设，按照相关监管要求，最终设定一类业务系统的 RPO=0，RTO<30 分钟。为了尽量的缩短业务恢复时间 RTO，需要减少人工进行故障分析、并执行人工切换系统的操作，故最终采用 VPLEX Metro+Oracle Extent Rac 的方式来避免在数据层面花费较多的时间执行数据库故障的判断和切换，而应用层面通过前端的负载引流实现应用的高可用。
VPLEX Metro 能够为主机提供跨站点的共享存储，两个站点都能同时读写同一份数据。VPLEX Metro 下存储的逻辑结构如下所示：
Dell EMC VPLEX Metro 打破了数据中心的物理壁垒，允许用户并发访问位于不同地理位置的数据。采用 VPLEX Metro 的扩展Oracle Extent RAC 允许访问单个数据库时在多个站点之间透明地共享工作负载，同时可以在预见到计划内事件（例如硬件维护）时灵活地迁移站点间的工作负载。此外，如果发生的计划外事件导致其中一个数据中心中断服 务，则可使用 Oracle Transparent Application Failover (TAF) 自动地将出现故障的客户端连接重定向到仍正常运行的站点上运行的 Oracle RAC 节点。
在同城双中心使用 VPLEX Metro 构建存储双活，在此基础上实现 Oracle Extent Rac。并在同一中心部署 ADG 的只读库，进行读写分离，主要用于一些报表和没有时限严格要求的查询类业务。
同时针对误操作或逻辑错误进行规划设计，使用持续性数据保护+长期备份归档的的体系来保障数据的安全。针对数据库的数据保护，使用 Oracle 数据库的数据复制技术 ADG 并结合闪回功能，能够快速回滚到故障发生点，进行数据的查询和恢复，必要时可以将业务切换到 ADG 数据库进行运行。同时使用备份系统定期进行长期数据备份归档，以满足间隔时间较长的数据的恢复需求。而应用系统文件系统中的重要数据，通过 Recovery Point 的CRR 进行持续的数据保护，同时辅以备份系统进行长期的数据备份归档，在发生误操作或逻辑错误时可以通过 CRR 快速恢复近期的数据，而间隔较远的时间点的数据可以通过备份系统进行恢复。
2.2.2.2 异地灾备
异地灾备按照信息系统灾难恢复等级 5 级的标准进行建设，最终设定一类业务系统的RPO<15 分钟，RTO<300 分钟。
在数据库上，关键业务系统数据库采用 Oracle ADG 进行数据库的灾备建设，从生产中心的 ADG 数据库将数据复制到异地灾备的数据库。而应用系统和其他的数据库使用 Dell EMC Recovery Point 进行CRR 的数据保护，通过生产中心的的 Recovery Point 将数据发送到灾备中心的 Recovery Point 进行数据保护。
同时将同城双活中心的备份数据复制到异地灾备中心，满足备份归档异地存放的需要。
3. 关键问题
两地三中心的建设，是为业务连续性提供服务，在发生故障后，尽最大可能的保障数据能够被恢复，业务能够快速的恢复服务。因此在整个方案中需要尽可能多的假设各种故障场景，考虑各场景的应对方案，才能尽量减少在系统运行中发生的预期外的异常，保障系统的正常运行。
在整个方案中，重点需要关注以下的几个方面。
3.1 仲裁一致性问题
VPLEX Metro+Oracle Extent Rac 的方案，关键在于仲裁一致性的设计以及双活中心间链路带宽和延迟。为防止 VPLEX Metro 的仲裁和 Oracle 的仲裁出现不一致的情况，需要先了解两种仲裁的机制和情况，在考虑如何避免仲裁不一致。
3.1.1 VPLEX 仲裁
VPLEX 有一套自己的防脑裂机制：分离规则和VPLEX Witness。
分离规则
分离规则是在与远程群集的连接中断（例如，网络分区或远程群集故障）时，确定一致性组 IO 处理语义的预定义规则。在这些情况下，在恢复通信之前，大多数工作负载需要特定虚拟卷集，才能在一个群集上继续 IO 并在另一个群集上暂停 IO。
在 VPLEX Metro 配置中， 分离规则可以描述静态首选群集， 方法是设置： winner:cluster-1、winner:cluster-2 或 No Automatic Winner（无自动优胜者）（其中，最后一项指定无首选群集）。如果部署的系统没有 VPLEX Witness（将在下节中论述），一致性组设备 IO 将在首选群集中继续，并在非首选群集中暂停。
VPLEX Witness
VPLEX Witness 通过管理IP 网络连接至两个VPLEX Metro 群集。VPLEX Witness 通过 将其自身的观察与群集定期报告的信息进行协调，让群集可区分群集内网络分区故障和群集故障，并在这些情况下自动继续相应站点上的 IO。VPLEX Witness 仅影响属于 VPLEX Metro 配置中同步一致性组成员的虚拟卷，并且仅当分离规则指明群集 1 或群集 2 是一致性组首选群集时才会影响。没有 VPLEX Witness 时，如果两个 VPLEX 群集失去联系，生效中的一致性组分离规则将定义哪个群集继续操作以及哪个暂停 IO，如上所述。仅使用分离规则来控制哪个站点是优胜者时，可能会在出现站点故障时增加不必要的复杂性，因为可能需要手动干预才能恢复仍正常运行的站点 IO。VPLEX Witness 会动态地自动处理此类事件，这也是它成为扩展 Oracle RAC 部署绝对必要项的原因。它提供了以下几项内容：
在数据中心之间自动实现负载平衡
主动/主动使用两个数据中心
存储层的完全自动故障处理
为了让 VPLEX Witness 能够正确区分各种故障情况，必须使用互不相同的网络接口在独立于任意群集的故障域中安装它。这将消除单个故障同时影响群集和 VPLEX Witness的可能性。例如，如果将 VPLEX Metro 配置的两个群集部署在同一数据中心的两个不同楼层，请在不同楼层部署VPLEX Witness。另一方面，如果将VPLEX Metro 配置的两个群集部署在两个不同的数据中心，请在第三个数据中心部署 VPLEX Witness。
VPLEX Witness 仲裁的场景如下所示：
1、Witness 或Witnes 网络连接故障
2、 Cluster2 故障或Cluster2 与Witness 通讯故障
3、 Cluster1 和Cluster2 之间复制链路故障
4、 Cluster1 和Cluster2 之间复制链路故障同时Witness 与Cluster2 通讯故障
3.1.2 Oracle 仲裁
⽹络⼼跳
⽹络⼼跳主要是确保集群节点间的连通性，以便节点之间能够了解彼此的状态。ocssd.bin 进程每秒向其他节点发送⽹络⼼跳，通过⼼跳情况确认节点的连通性，以及当⽹络⼼跳出现问题时做出处理。若某个节点的网络心跳在 misscount 指定的秒数中都没有被收到的话，该节点被认为已经“死亡”。在出现集群分裂的情况下，基于简单多数原则，拥有节点数量多的子集群存活。若是节点数一致则 RAC 会选择保留拥有最低节点号节点的子集群。
磁盘⼼跳
如果由于⽹络⼼跳异常，导致集群出现脑裂的发⽣，磁盘⼼跳则帮助解决该问题。Oracle 集群的每㇐个节点每秒都会向集群中所有的表决盘注册本地节点的磁盘⼼跳信息， 也就是说，所有的Voting File 的信息是相同的。同时会将⾃⼰能够联系的到的集群中的其他节点的信息，或者说本地节点认为集群中的成员列表信息填⼊到表决盘中。㇐旦发⽣脑裂， CSS 的重新配置线程就会通过表决盘的信息了解集群节点间的连通性，从⽽决定集群会分裂成⼏个⼦集群，以及每个⼦集群所包含的节点情况和每个节点的状态。如果发现某个节点在指定的时间内没有写入磁盘心跳，这个节点就被判决为死亡。如果一个节点处于未知状态，其他节点也会通过更新它的 voting disk 上的 kill block 状态的方式把它驱逐出集群。
总的来说，网络心跳每秒都会发起，如果一个节点超出了参数 css_miscount time 设定的时间没有响应，就会被踢出集群。类似的，集群里的每个节点每秒读写voting disk 特定区域，出现超时响应的节点也会被踢出集群。发生集群分裂的情况下，根据表决盘中的信息，判断集群分裂情况，按照简单多数原则和最低节点号的原则保留活动节点。
3.1.3 VPLEX 和 Oracle 仲裁一致性
为了减少脑裂情况的发生并且在发生脑裂时保持仲裁的一致性，在设计时需要遵循的原则：
1、在设计时将 VPLEX 的 winner cluster 节点和 Oracle 的 Lowest Cluster ID 节点部署在同一个站点
2、Oracle Clusterware 文件（OCR 和表决文件）应部署在VPLEX Metro 的分布式卷上，使 Oracle 仲裁的磁盘心跳依赖于 VPLEX 的仲裁，以便能够保持 VPLEX 和 Oracle 仲裁的一致
3、Oracle RAC 的 misscount 大于 VPLEX Winner: cluster-x delay_time。
4、Oracle Rac 的心跳网络和VPLEX Metro 的复制网络需要采用冗余设计，避免单点故障的发生
5、在第三站点部署Witness，Witness 与VPLEX Metro 的两个 Cluster 采用独立的网络连接
在发生双活中心链路中断问题时，VPLEX 先进行仲裁，保留一个站点的 IO 读写（此过程 IO 会 hang，默认为 5S），假设为 A 站点。另外一个站点的 IO 将被Suspeded，假设为 B 站点。这时无论Oracle 心跳网络是否正常，则 B 站点的节点都因为不能访问表决盘将会被踢出集群并重启，而A 站点的节点继续提供服务。
而在一些特殊的场景下，会发生两个站点都不能使用的情况，如：在VPLEX Metro 链路断开后重新恢复时，两个站点的数据正在进行同步，假设从A 站点同步到 B 站点，这时若发生A 站点的故障，则 B 站点由于Oracle 节点不能对 B 站点的VPLEX 进行正常的读写，导致 B 站点的Oracle 节点也出现宕机，该情况下可能出现数据不完整导致 B 站点的Oracle 服务需要进行恢复才能提供服务，并且存储数据丢失的问题。针对此类情况，只能通过其他的保护机制进行业务连续性的保护，如在本方案中除采用 Oracle Extent RAC 外还使用了ADG 进行数据保护。
3.2 同城双活中心间链路抖动问题
若出现链路延迟较大或者频繁出现连接中断，都可能会对系统的运行造成重大影响。双活中心的链路质量需要注意的事项：
1.在进行链路设计时，需要充分考虑链路的冗余。从波分设备、交换机、存储和主机接入都需要进行详细的规划设计，保证任一环节不存在单点故障。而对于不受控的运营商线路，需要同时租用两家以上的运营商裸纤，有条件的话，对运营商的裸纤的路线和进入数据中心的弱电井等进行详细了解，尽量避免存在物理空间上的交叉。
2.对链路质量进行检测，包括光衰、延迟、抖动等。最好在双活建设之前进行链路质量的测试和检测，及时发现问题并与运营商进行沟通处理。
3.做好链路抖动或延迟大的处理预案。当出现链路抖动或者延迟大的情况下，需要按照设计好的方案断开线路，已保障其中一个站点能够正常的提供服务。结合自动化运维监控，在发生该问题时，能够自动切断链路，一边在一个中心正常提供业务。
3.3 性能下降问题
由于在存储双活方案中采用双写保证数据的一致性，故对于数据写操作的延迟会增加， 特别是采用 VPLEX 类似的存储网关方案时较为明显。在系统并发写操作大时，写 IO 的延迟会明显增加，系统的 TPS 将会受到影响。故需要在投产之前做好性能压力测试，已满足投产后的正常运行。
另外，在VPLEX Metro 双站点间链路中断的情况下，IO 将会 hang 住 5 秒，在这 5s 内产生的会话连接将会消耗主机 CPU、内存资源，若是每秒 1000 个数据库并发的情况下， 将会产生 5000 个的会话连接，需要根据实际情况估算数据库主机的相关资源，以免在 IO hang 的期间将主机资源耗尽从而导致宕机。
3.4 运行维护问题
双活容灾解决方案将灾难切换变的较为简单，但在实际的维护方面并不简单，除了要求用户提升自己的维护能力，还需双活容灾解决方案供应商的售后服务能力。
用户自身人员的维护能力必须加强，才具备能力维护跨站点的双活系统。
用户运维人员必须从维护设备的能力转变为具备维护双活系统架构的能力，需要深入了解双活架构中的各个环节，才能保障系统的正常运行。
双活容灾解决方案供应商的售后服务能力
供应商的服务能力也直接影响双活容灾系统部署后的效果，在许多的案例中，经常看到供应商提供了 800 电话，但却不能及时安排技术人员现场服务。整个服务过程重复的在收集日志进行诊断，在问题出现的时候，难以尽快解决问题，这样的方式如何保障双活容灾系统的稳定？所以后期的有效沟通和及时的技术支持是需要关注的问题。
需要结合运维监控和运维自动化完成双活数据中心的运行管理。
假设双活中心的中间链路出现抖动，导致IO 延迟大，若没有完善的监控系统，我们发现的时候可能主机已经由于不能正常进行 IO 读写而导致了宕机。即使有监控系统，并且已经发送告警给系统管理员，但是系统管理员需要登录相关设备进行问题查看，并按照应急的方案进行处理，这个过程是需要时间的。若是在业务高峰期发生该情况，将对大量的业务交易造成影响，甚至由于宕机而导致一段时间的业务交易不能正常进行。故需要结合运维监控和运维自动化系统，由系统快速的做出响应。
4. 总结
在实际的灾备建设中，常常会听到双活容灾方案可以让生产中心和容灾中心都“活”起来，有效的利用资源，在发生关站点级的故障时，最大化业务系统的可用性，而异地灾备的建设满足了发生重大灾难性事件时数据恢复和业务连续性的需求。
但是，当我们认真考虑双活+异地容灾系统建设时发现，如果自身信息技术人员的维护能力不足，很难达到我们期望的效果。双活+异地容灾涉及多个厂商的产品和解决方案，方案的规划设计、系统集成较为复杂，若没有一支专业的运维团队支撑后期的运行维护，整个方案将不能达到预期的目标。
点击文末阅读原文，可到社区原文下提问交流，或下载原文文档 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 "存储双活"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/1431
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场